敏捷的由來
『敏捷』（Agile）一詞的由來是 2001 年由 17 位軟體開發的專家們齊聚在美國猶他州雪鳥滑雪場聚會時提出，這群人也就是敏捷宣言的發起者。這次的聚會也提出了著名的『敏捷軟體開發宣言』與『敏捷 12 原則』。這群人中包含了幾位大家熟知的軟體圈大師 Kent Beck（極限編程的創始人）、Martin Fowler（知名著作『重構』的作者）。

瀑布開發方法 vs 敏捷開發方法
談到『敏捷開發方法』（Agile Methodology），就會提到另一種開發方式稱為『瀑布開發方法』（Waterfall）。1970 年，Winston W. Royc 提出一種『瀑布開發模型』，將軟體的開發分為幾個階段，分別為：

1. 系統需求（System and software requirements）：撰寫產品需求文件。
2. 分析階段（Analysis）: 分析需求與商業邏輯。
3. 設計階段（Design）: 將需求進行軟體的架構設計。
4. 實作階段（Coding）:開始進行開發實作與整合。
5. 測試階段（Testing）: 測試驗證需求，並找出系統缺失進行修正。
6. 營運階段（Operations）: 安裝、整合、上線與維護。

這個方法，需要對需求與技術有充分的了解後，才能進行設計與實作，最後經過驗證階段的確認，產品才能上線營運。整體所需要的時間比較長，優點是『完整的規劃，讓進行時比較流暢，有明確的時間、需求範圍』，但缺點是『完美計畫通常趕不上變化，有固定的時間及需求產出物，也表示發生變化時，在不影響時間（Time）與範圍（Scope），只能犧牲成本（Cost），包含投入更多人力或加班。此外，在上游卡住時，下游也只能等待，無法幫忙，最後犧牲的通常是實作階段的人力投入更多，或是測試階段犧牲品質。』

什麼是敏捷？
什麼是『敏捷』？很多人聽到『敏捷』第一個直覺就是開發的速度會比較快，開發的時間會比較短。但是實際上『敏捷』所提倡的觀念並不是速度比較快或時間比較短，而是面對不確定的事能具備快速反應的敏捷能力。

很多人都認為導入『敏捷』後，很多困難或複雜的事就會迎刃而解，但是實際『跑過敏捷』（這裡故意用『跑過』是指像是儀式般把流程跑完）後會發現事情不僅沒有更簡單，而且變得比還沒跑敏捷前更複雜了。但事情的複雜並不是跑敏捷才複雜的，而是跑了敏捷後問題越容易浮現出來。

從過去的經驗裡，我發現如果只是一味的想透過敏捷來解決問題，到最後問題並不會比較少。但如果是理解敏捷的精神，透過小規模嘗試，（Divide & Conquer），持續的迭代，找出問題對症下藥，不僅產品，團隊的效能也會越來越好。
那什麼是敏捷呢？我覺得『敏捷』不僅是方法論，而是你可以試著驗證個人、團隊、產品、組織面對問題的態度是否也『敏捷』。『敏捷』不該只是口號，做比說更重要，失敗比成功更有價值。

其實我不喜歡談『敏捷』，而是喜歡反思我們面對事情的心態是什麼？世界上唯一不變的就是改變，你接受不確定性嗎？你接受快速嘗試，持續優化嗎？你同意『導入敏捷』最重要的是先改變自己嗎？

分享一篇文章『以敏捷為名，卻變得更不敏捷》敏捷法不出錯的六大關鍵』，我只能說『敏捷、敏捷、多少罪惡假汝之名以行』。敏捷值不值得吃呢？吃的目的是活下來。如果吃了一個東西沒辦法幫助你活下來，而且還會死更快，你就該在吃之前好好考慮清楚。

原文請參考：【文思不藏私】 敏捷幼幼班～敏捷能吃嗎？